The present disclosure relates generally to processing during critical processing sections and, more specifically, to managing control loss when processing during critical processing sections.
For example, during file processing, critical sections of the file process are not allowed to lose control from an application point of view. This means the request to perform the file cannot lose control. For example, when a system files records out to disk new support may be provided to capture a copy of the record being filed and push a copy of that record out to event processing. In that example, copies of the original record are created, allowing the file process to not relinquish control. For example, one may file a copy to a local disk, and the system takes a copy of that and sends a copy of the record to one or more remote systems for archiving or analytics etc. Accordingly, any requests to file records within a transaction scope are kept pending within the transaction scope until the transaction scope is committed to disk. Only when the transaction scope is committed are all the held requests either committed to, or if a roll back is requested they can all be dropped.
Thus, as described above, while performing critical section processing it is sometimes the case that the critical section is not allowed loss of control. In addition, the file request may be performed within a transaction scope. This means that the critical section does not fully release any processed requests. Rather, the processed requests are held until the entire transaction scope is complete and are either selected to be committed or can be rolled back which causes all the requests to be discarded. Further, it can be the case that all supporting functions and processing invoked in the critical section may not lose control either. In some instances, the critical section may be very large, which may significantly restrict which supporting functions can be used and make it difficult to call other processing or functions.
One way to try and handle the processing is to push the collected data for the data event to a shared queue or list and have an asynchronous process continue processing the data event. However, this method would put the data event outside the control of the application transaction scope and the data event could still flow even if the application transaction scope is rolled back.
Another method is to delay creating the data event and collecting data until the application transaction scope is committed. Instead of recognizing a data event at the FILE API time, it would be recognized at commit time. However, the contextual data needs to be collected at the FILE API time and would no longer be available at commit time.
Accordingly, there is a desire to provide a method and system that can help processes during critical processing sections when relinquishing control is not desired.